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Abstract 

Development costs of a few recent spaceflight 
instrument electrical and electronics subsystems have 
diverged from respective heritage cost model predictions. 
The cost models used are Grass Roots, Price-H and 
Parametric Model. These cost models originated in the 
military and industry around 1970 and were successfully 
adopted and patched by NASA on a mission-by-mission 
basis for years. However, the complexity of new 
instruments recently changed rapidly by orders of 
magnitude. This is most obvious in the complexity of 
representative spaceflight instrument electronics' data 
system. It is now required to perform intermediate 
processing of digitized data apart from conventional 
processing of science phenomenon signals from multiple 
detectors. This involves on-board instrument formatting of 
computational operands from row data (for example , 
images), multi-million operations per second on large 
volumes of data in reconfigurable hardware (in addition 
to processing on a general purpose imbedded or stand- 
alone instrument flight computer), as well as making 
decisions for on-board system adaptation and resource 
reconfiguration . The instrument data system is now tasked 
to perform more functions , such as forming packets and 
instrument-level data compression of more than one data 
stream, which are traditionally performed by the 
spacecraft command and data handling system. It is 
furthermore required that the electronics box for new 
complex instruments is developed for one-digit watt 
power consumption, small size and that it is light-weight, 
and delivers super-computing capabilities. The conflict 
between the actual development cost of newer complex 
instruments and its electronics components’ heritage cost 
model predictions seems to be irreconcilable. This 
conflict and an approach to its resolution are addressed 
in this paper by determining the complexity parameters, 


complexity index, and their use in enhanced cost model 

1.0 Introduction 

The representative complex spaceflight instruments and 
prototypes are, for example, the Ocean Carbon Ecosystem 
and Near Shore Processes Mission (OCEaNS) optical 
instrument with high volume and high rate data streams 
from its focal planes and requiring on-board digital time 
delay integration. The non-optical Magnetospheric Multi- 
Scale Fast Plasma Investigation (MMS/FPI) instruments 
require on-board intensive computation of the Burst 
Quality Index. The Laser Interferometer Space Antenna 
(LISA) may require quad precision floating-point 
arithmetic computations and the Solar Viewing 
Interferometer Instrument Prototype (SVIP) is based on 
image processing within fast attitude control loops. A 
complex instrument is one that has large arrays of large 
detectors at fast readout rates, producing signal volumes 
and rates of order of magnitudes higher than heritage 
instruments and instrument based random access memory 
around 500 megabytes, and requiring non-trivial analog 
signal and digital data processing on-board the instrument. 

There is a solution - to fly a super-computer, but 
obviously, it is not feasible. There is another solution at 
the other end of the spectrum of possible solutions. It is in 
utilizing reconfigurable hardware (RC) to achieve on- 
board super-computer power as a substitute for a super- 
computer. However, this technologically possible solution 
is tempting, at the conceptual design phase, to make an 
assumption that this solution can be implemented by the 
heritage design methodologies of scaling up a heritage 
instrument design (“a bigger box” approach). This turns 
out to be a strong assumption and at the following design 
development and implementation phase results in merely a 
partial solution. In turn, a partial solution invariably 
requires re-designs during the development phase, which 



leads to divergence of development costs from cost model 
predictions. 

In order to find the full design solution for a complex 
instrument at the outset conceptual level and cost the full 
design, the instrument complexity parameters must first be 
determined from the requirements and accounted for in the 
conceptual design. The complexity parameters and the 
conceptual design to these complexity parameters must 
then be included in the instrument cost model. Once the 
instrument complexity parameters are analyzed then the 
labor and hardware cost, required for the instrument 
design to these parameters (Section 8), can be estimated 
using heritage cost models or accounted for in the 
enhanced cost model and alleviate the cost divergence 
problem. 

The elaboration of the complexity parameters in this 
paper in Sections 2-7 is straight- forward, including the 
framework for the proposed enhanced cost model that is 
using these complexity parameters and the complexity 
index derived from them, as well as the empirical cost 
factor based on the complexity index. The design of the 
Electrical and Electronics (EE) Subsystem to the 
complexity parameters at conceptual phase is presented in 
Section 8. 

2.0 Complexity Parameters and the 
Enhanced Cost Model Methodology 

In order to develop an enhanced cost model for complex 
instruments, a few preliminary issues have to be discussed. 
Most subsystems within the newer complex instruments 
closely follow the typical heritage instrument. For 
example, their mechanical and thermal subsystems, except 
for change in dimensions for small satellites or large 
observatory, are similar to heritage ones. However, the 
requirements for the electronics’ data subsystem have 
undergone radical changes and its complexity parameters 
must now be reflected in the cost model. The sources of 
complexity are described below and the sequence of the 
complexity parameters can be depicted as selected points 
on the guideline from the heritage cost models to the 
enhanced cost model (Fig. 4). 

2.1 Sources of Complexity Parameters 

The complexity parameters are derived based on the 
detector analog signal and on-board digital data 
processing flow from the source phenomena to the 
spacecraft solid-state recorder (SSR), with the emphasis 
on their information communications’ aspects. The 
methodology we used in deriving the complexity 
parameters and the enhanced cost model can be described 
by enumerating the main points of the analysis followed 
by enhanced cost model framework synthesis. The on- 
board sources of analog signals and digital data are: 


• External to spacecraft and instrument 

o Science Phenomenon (measured by 
large arrays) 

o External Calibration Sources (Analog - 
distant star, sun, moon) 
o Spacecraft Commands (Digital Data 
from Ground/Space Link) 
o Global Positioning System (GPS) 

Position Data and Time Signals 

• Internal to spacecraft and instrument 

o Science Analog-to-Digital Conversion 
Output 

o On-Board Intermediate Data Processing 
Results 

■ Pre-Processing i.e. frame 
formatting, packetization 

■ On-board Processing i.e. signal 
processing, time delay 
integration, data compression, 
time tagging and high 
performance computation 

• Engineering 

o Internal Calibration Sources 
o Housekeeping Data Sources 

2.2 Methodology Developmental Steps 

The enhanced cost model methodology is derived using 
the following steps: 

• Construct Informal Table of Signal and Data 
Sources 

• Construct Formal Classification Matrix of 
Analog Signals, Digital Data Sources 

• Determine Relation Between Source Signal Pixel 
and Detector Super-Pixel 

• Map Signal Sources Onto Instrument Detectors 
and Describe On-Board Data Processing 
Complexity Parameters Origin 

• Demonstrate Instrument Cost Model emergence 
from heritage cost to the enhanced cost model. 

2.3 Cost Models and Complexity Cost 
Distribution Outline 

The Heritage Cost Models (HCM) are denoted as u and 
are based on the four primary parameters of two functions 
f v , f vr representing an implementation labor and heritage 
hardware cost parameter H and defined as 

V-f 9 (P,D) 

v r = fvr( P r- D r) 

u = /„ (. f v (P, D ), f vr {P r ,D r ),H) = f u {P, D, P r ,D,.,H) 



where P is the number of analog signals, D is the number 
of digital signals, P r is sampling rate for analog signals, D r 
is sampling rate for digital data and H is the heritage 
hardware cost parameter. 

The enhanced cost model (ECM) function U is derived 
based on the heritage cost model u parameters and the 
derived complexity parameters of functions V and V r 
implementation labor. The ECM function U depends on 
design of the reconfigurable hardware (RC) to the 
complexity parameters and complexity index K , derived 
from the instrument data system complexity parameters, as 
described in the following sections. The complexity 
parameter functions V, V r and U are defined as 


• Complexity costs are manually converted by a 
user to costs in terms of labor and hardware 
inputs, when a heritage cost model is used; Even 
a heritage cost model u results in more accurate 
cost predictions, if all complexity parameters are 
taken into consideration at conceptual design 
phase 

• In future work, one of the heritage cost models 
shall be modified to include complexity 
parameters in its database, yielding the enhanced 
cost model implementation as a new commercial 
tool. 


V = max(P, S, D, I, F, R, O, f,A,M ) 

V r = max (P r ,S r ,D r ,I r ,F r ,R r ,O r ,f r ,A r ,M r ) 

U = f u (V,V r ,RC,K(V,V r )) 


= fu 


' P,S,D,I,F,R,0,f,A,M,P r ,S r ,D ) r > 
J,.,F r ,R r ,O r ,A r ,M r ,RC j 


where P, D, P r and D r were described above, S and S r are 
the size and rate of the detector super-pixels, I and I, are 
intermediate data volume and rate, F and F r are native 
pixel-frame size and rate for a required full readout of a 
sensor, R and R r are compression reduced data volume and 
rate, O and O r are the number of operations per second to 
be performed by on-board computation algorithms and 
data stream rates for the computational operands, / is the 
software and firmware size, A is the arithmetic complexity 
parameter and M is the parameter reflecting the 
complexity of the simulation model. These parameters are 
derived below. 


2.4 Placement of Complexity Costs 

The placement of costs, induced by instrument electronics 
subsystem complexity index, K, in the enhanced cost 
model is of most importance. It is not in scaling up the 
direct labor or hardware costs for a heritage design and 
implementation or its funding reserves in which the 
complexity parameters are not costed one by one. The 
placement of cost in the enhanced cost model should 
rather be in the labor and hardware costs for finding a full 
solution and design that includes all complexity 
parameters one by one. The cost should also account for 
labor and hardware needed for pre-optimizing the design 
for an instrument with the index of complexity K and for 
tuning a complex electronics subsystem at all phases along 
the design implementation path. In other words, the 
placement of the costs associated with the EE subsystem 
complexity occurs at all the phases of a project life cycle 
and can be accomplished in two ways: 


In both case the cost of complexity parameters can be 
derived based on: 

• Requirement Complexity Analysis 

• Complexity risks assessment and 
mitigation by pre-proposal studies and 
RC hardware simulations 

• Finding a solution at conceptual design 
phase 

• Synthesis of solution, including RC 
algorithms pre-hardware optimization 

2.5 Implementation Steps 

• Instrument Data Processing Unit (IDPU) 
complexity implementation options are analyzed 

• Design of a complex instrument to the 
complexity parameters is implemented at 
conceptual level and costed using the enhanced 
cost model framework. 

3.0 Sources of Instrument Analog Signals and 
Digital Data 

Heritage instruments were “throughput systems” from an 
instrument focal plane sensor assembly (FPA) source to 
destination - the spacecraft computer system and its solid- 
state recorder (SSR), in relation to the analog signal and 
digital data communications aspect. For example, a 
heritage instrument, such as the SeaStar spacecraft Wide- 
Field-of-view Sensor (SeaWiFS) instrument comprises a 
few sensors with a small number of homogeneous source 
pixels - a source of a small number of analog signals P 
that are sampled at moderate sampling rate P r . After 
digitization of P by the instrument, the digital data is the 
instrument output at data volume and rate (D, D r ). The 
digital data is then just forwarded to the spacecraft for 



processing and compression by one of the spacecraft 
computers and storage in the spacecraft SSR. The digital 
data volume essentially amounts to the volume of source 
pixels P multiplied by the analog-to-digital conversion 
(ADC) word length (usually => 10 to 16 bits), while the 
digital data rate in words is the same as the rate of source 
pixel signal sampling. Exception among heritage 
instruments was a large Observatory with complexity 
handled by costly Application Specific Integrated Circuits 
(ASIC). However, the large observatories, long-term 
schedules and multi-million dollars ASICs are not a 
common option today. 

Representative advanced instruments are much more 
complex with strict cost and schedule constraints. These 
instruments study multiple non-homogeneous phenomena 
at different sampling rates and digitization resolution, and 
required to perform computationally intensive on-board 
digital data processing. For example, On-Board fast optics 
control loops require processing by the instrument of large 
CCD images (512 x 256 pixels) at hundreds of frames per 
second. 

This requires a new look at the effects of different signal 
and digital data sources and their volumes and rates on the 
instrument power consumption and cost, in order to 
enhance the instrument electronics cost model at early 
stages of the instrument conceptual design, when 
instrument initial complexity and cost are evaluated at 
proposal and feasibility studies’ levels. 

The complexity parameters were not accounted for in 
heritage instrument cost models. The impact of complexity 
parameters for heritage instruments was so negligent, in 
comparison with that in newer instruments, that they could 
be reasonably ignored at conceptual level design. 

For newer advanced instruments any omission of 
complexity parameters in costing the on-board data 
processing at the conceptual design or the Technical 
Management Review (TMR), or in the Final Proposal, 
could result in eventual cost underestimation and schedule 
overruns. 

In order to derive complexity parameters for new 
instruments there is a need to derive a set of all signal 
sources and data in the form of a matrix. This matrix can 
be used in new complexity parameter derivation. The 
remainder of this section will explain in detail the signal 
and data source matrix derivation. 

3.1 External to Instrument and Spacecraft Signal 
Sources 

3.1.1 Science Signal Sources 

The advanced subject instrument’s science and 
engineering (calibration or housekeeping) signals originate 
from some physical phenomenon. The science data 
originates with measurements by the instrument detectors 
of the source signals’ amplitude. 


3.1.2 External Calibration Sources 

To maintain the calibration system on-board, it is 
desirable to obtain reference calibration source 
measurements throughout the operational phase of a 
sensor. There are various calibration sources external to 
spacecraft being used for calibration system as: Distant 
Star, Sun, Moon, Orbit Night Sky or Spacecraft Dark 
Side, Earth Horizon and Bright Cloud. 

3.2 Internal or Engineering Signal Sources 

The engineering data originates within the instrument 
itself, namely the housekeeping detectors (thermal, 
pressure, force gouges, instrument or spacecraft power 
sources and other sensors) or instrument science detectors 
calibration sources, which are emulating natural physical 
phenomenon for the science physical phenomena 
detectors. 

3.2.1 Calibration Signal Sources 

Instrument-carried calibration sources - hot/cold plates, 
illumination spheres, etc. 

3.3 Instrument Digital Data Sources 

There is also some instrument digital data that originates 
in the instrument data (information) system apart from its 
detector signal ADCs (computation registers, intermediate 
digital data, telemetry format headers memory, SSR), and 
which needs to be transmitted to upper nodes of the 
spacecraft for communication to the ground control station 
or other spacecraft in a constellation. The physical 
phenomena itself can be comprised of electromagnetic 
radiation in different spectral ranges (ultra-violet, visible 
light, near Infrared or IR, thermal IR, communications 
radio-frequency or RF waves), mechanical forces, 
gravitation, chemical processes. These are also termed 
analog signals and, in turn, may have as their sources the 
sun, moon, a star, celestial background radiation or 
surface of planets - earth land and oceans’ upward 
irradiation. Communications RF sources are, for example 
— commands , up-linked from a terrestrial or space control 
center to spacecraft and instrument. 

3.4 Informal Signal and Data Sources 
Classification Table 

Pictorially the set of all instrument analog signal and 
digital data sources, which contribute to instrument 
information, can be represented in an informal Table, 
Figure 1. 

The informal multi-classification of instrument analog 
signal and digital data sources in Figure 1 can be further 
formalized into extended matrix as depicted in Figure 2. 



Phenomena of 
Science interest, 
Calibration 
Sources Signals 
Class 1 : 

S U> Sj 2 ... s lk 

House-Keeping 
sources and signals 
(H/K), 
Thermistors, 
Mechanisms’ 
Position sensors or 
Signal Class 2: 
s 2 i ... s 2 „ 

Commands 

Internal to 

(CMD) or 

instrument 

Signal Class 3: 

Digital Data 
Sources & 
Computations 
(IDS) or 
Signal Class 4: 

S31 ••• 83m 

S41 ... s 4v 


Figure 1. Classification of Instrument Analog 
Signals and Digital Data Sources 

4,0 Formal Classification of Sources 

The source with most elements (H/K is perhaps the one, 
because it contains dozens of thermistors) is 
{S 21 ... s 2n } 

It comprises the class of the longest non-zero energy 
source of signals. Other sources for other analog signals 
and digital data are extended by zero-value elements to 
yield a sparsely populated “4 x n” rectangular extended 
matrix of instrument data sources. 


Sll S 12 ... S^Oik+1 ••• Oln 

s 2l S 2 2 ... S 2n -1 S 2n 

S3I S 3 m 03 m +i ... O311 

S 41 ... S 4v 04v+i . . . 0 4n 


Figure 2. Extended Matrix of Instrument Data Sources 

This formal classification matrix is used in the following 
sections to derive the new instruments complexity 
parameters, which are, in turn, used to develop the 
enhanced cost model for the electronics subsystem. 

5.0 Mapping Signal Sources onto Instrument 
Detectors 

We will examine now the propagation of the signal and 
data elements from the formal matrix of sources (Figure 2) 


throughout an instrument and associated complexity 
parameters. 

A physical phenomenon manifests itself in emanated 
energy from some finite size (for example, 1 km x 1 km) 
surface or volume region - source signal pixel and this 
energy is being intercepted by an instrument detector, as a 
sub-pixel, pixel or super-pixel (binning of a few adjacent 
CCD pixels, for example (Figure 3). 


5.1 On Source Signal Pixels and Detector 
Super-Pixels 

A Source is usually associated with some finite size 
geometric space, say a terrestrial 2-D surface or 3-D 
volume (source pixel), or a small spot on an instrument 
surface for mounting a thermistor - a temperature signal 
detector as listed in Figure 1 above. For example, consider 
two sources: 

A ground track of dimensions L x h with a Ground pixel 
of size h x h and 

A spot on an instrument surface of radius r for mounting 
a thermistor 

Stylized Swath of L Source Pixels 


Ground Track scanned by a 
spacecraft instrument 



A circular spot on instrument 
surface to mount a thermistor 


Figure 3. Geometry of Source Pixels 


The number P of source pixels for the instrument is the 
sum of all non-zero elements in the above matrix M: 

P = Z(Sij) 

5.2 On Mapping Signal Sources onto Detectors 
and Complexity Parameters 

Instrument sensors invariably comprise a set of detectors 
or sensing pixels out of which a super-pixel dy of size Z 
(say, Z = 3 x 3) is comprised. For example, a CCD 
comprises a 2-D array of (n x m) sensing pixels that can 
be organized into a set of super-pixels on the CCD itself. 
An InGaAs linear array comprises a linear array of (1 x k) 
pixels and a housekeeping thermistor sensor usually 
comprises a single pixel thermal detector. 

Each signal source Sy is further defined by its 
measurement interval ty in fractions of a second (or 
sampling rate derived from this time as its inverse with 
frequency in Hz units). 





Although the sampling of different sources may not be 
asynchronous, the source sampling interval provides the 
definitive answer on the information volume of a signal 
source from communication point of view - in terms of 
source measured pixels per second. 

It is obvious that at some time T the different samplings 
may intersect in time and that the instrument must be 
designed to handle the maximum combined data volume 
rate of 

Pr = Z( s ij / hj) 

pixels per second for all i, j; the division is 0 for Sy=0. 

P and P r , the volume of the instrument observed source 
pixels and sampling rates handled by the instrument are 
the two important first parameters to consider in the 
evaluation of the instrument complexity and cost or I cc : 

I cc = f({P,P r }...) 

Next, the energy of a group of adjacent source pixels sy 
energy is intercepted by an optical system and 
concentrated on a so-called Time Delay Integration slit of 
length determined by the TDI-size. This slit length L (in 
adjacent source pixels) is mapped into a TDI-size = L 
detector’s spectrometer and each TDI input pixel is 
distributed over a column of detector L super-pixels dy. 

A source pixel’s energy may further be practically 
instantaneously distributed in some spectral band over a k- 
row of dy* detector super-pixels (CCD row) by different 
optical means, such as diffraction gratings. 

This mapping of physical phenomena source pixels Sy 
onto instrument detector pixels results in the next level of 
data complexity, the number of detector super-pixels S, 
namely 

S = ( S(dij) ) / Z >= L x X 

It is reasonable to evaluate the detector pixels’ sampling 
rate by above dy* and say that 

S r = I (dipVtij) 

The number S may be larger than P by an order of two 
magnitudes and it becomes the next important parameter 
in figuring out the Icc, namely: 

Icc = f({P, P r , ty}, {S, S r } ...) 
where S > (P x (k=>60)) or 

1 source pixel is mapped onto detector k spectral super- 
pixels on one CCD row per sampling time ty. 

The next level of instrument complexity stems from the 
detector super-pixel digitization into a fixed number of 
information bits b(dy*). This internal to the instrument data 
source is the detector source super-pixel analog-to-digital 
signal’s converter ADCy*, resulting in a detector pixel 
digital data volume and corresponding digital data rate 
from analog and ADC board to the instrument digital 
information processing board or instrument data 
processing unit (IDPU): 

D = X(dy*xb(dy*)) 

Dr = X( dy* X b(dy*) X ty ) 


D and D r are the instrument internal digital data volumes 
and rates that may be orders of magnitude higher than then 
the previous level parameters S and S r , which are related 
to analog data sources. This is because the digitization 
width b(d,j>) => W=>14 bits within advanced instruments 
of today and tomorrow and it further contributes to Icc: 

Icc = f({P, P r , ty}, { (dy, Z), X, S, S r }, {W, D, D r } ...) 
Next comes the on-board processing of the intermediate 
digital information within the instrument which involves 
transforming D, D r into Intermediate data I and 
Intermediate rates I r that may be larger than D and D r by a 
factor of L = 2 or more. For example, converting the 
W=14-bit ADC counters into a 32-bit integer or single 
precision floating-point numbers, doubles (32/14 = factor 
L>2) the volume and rate of ADC digital data to be 
processed within an IDPU or 

I = 2 x D 
I r = 2 x D r 

On-board post- ADC digital data Interpolation within an 
instrument IDPU (required in running some on-board 
algorithms) and data paketization overhead may increase 
the data volume and rate by a factor of L>10. Digital 
domain Time Delay Integration (TDI) may, in turn, 
decrease the intermediate data volume and rates at the 
price of required computational resources to implement 
the TDI algorithms. This further contributes to the Icc: 

Icc = f({P, P r , ty}, { dy*, Z, S, S r }, {W, D, D r }, {I, I r , L, 
TDI} ...) 

Instrument detector calibration and fault detection may 
require, for example, to dump the entire CCD or an IDPU 
memory region. This requires the instrument to be able to 
handle data rates determined by native pixel-frame size 
and rate of full dump, say F, F r or 

Icc = f({P, P r , ty}, { dy*, Z, S, S r }, {W, D, D r }, { I, I r ; L, 
TDI} {F, F r }...) 

Furthermore, instrument-level data volume Reduction 
using Compression techniques by a pre-determined 
minimum factor (for example 2:1 lossless compression) 
may also reduce the data volume and rate to R, Rr. It bears 
on instrument complexity and cost: 

Icc = f({P, P r , ty}, { dy*, Z, S, S r }, {W, D, D r }, {I, I r ; L, 
TDI}, {F, F r },{R, R r } ...) 

6.0 On-Board Computational Complexity 

There are several flight missions where processors have 
been used that demonstrates the on-board heritage 
computational resource: 

- FAST 10 MHz general-purpose processor 

- SeaStar 1 6 MHz 3 primary, 3 backup microprocessors 

- TRMM 133 MHz general-purpose processor. 



The heritage instruments, as exemplified by the 
instruments on spacecraft missions TRMM, SeaStar and 
FAST, could be characterized as 

Class (I): 

- High data volumes and rates 

- Electronics Box is essentially through-putting high rate 
data to spacecraft (SC) Solid State Recorder (SSR) 

- Low volume data is processed by the instrument data 
system computer 

- These instruments require only moderate computational 
performance software-centric and their software aspect 
is preeminent. 

Advanced complex instruments, such as the MMS/FPI 
instruments require more than 0=40 millions of 
computational operations per second on more than O r = 
10 million bits per second data streams in single and 
double precision floating point arithmetic. Complex 
instruments can be characterized as RC-Hardware-Centric 
Data Processing Instruments or 

Class (II): 

- High data volumes and rates 

- Electronics Box is performing on-board high intensive 
large volume data processing in RC hardware as 
opposed to heritage ASIC 

- The low volume housekeeping data is processed by the 
instrument’s data system general-purpose computer 

- These instruments are high computational performance 
RC-Hardware-Centric data processing instruments and 
their software computational aspect is minimal, while 
instrument flight software control aspect is still vital. 

It is obvious from laboratory simulations that by only 
changing the type of variables from single precision to 
double precision, increases a small application’s run time 
by a factor of. Changing data types 2 and to quad 
precision increases the run time by an order of magnitude. 
This is to simply demonstrate that on-board computations 
within an IDPU for an advanced instrument are not 
possible with heritage resources and requires FPGA 
implementations supplemented by host processors. In 
Class (II) instruments the Hardware (H/W) aspect of the 
Data System is the driver and the Software (S/W) aspect is 
minimal. This must be reflected in resource allocation, 
where 

S/W FTE « H/W FTE 

Because of this the computational complexity 
parameters O and O r (where often O r =D r ) must be 
included in the instrument IDPU conceptual design and 
cost model: 

Icc = f({P, P r , ty}, { dij„ Z, S, S r }, {W, D, D r }, {I, I r ; L, 
TDI}, { F, F r }, {R, R r }, {O, O r }) 


6.1 Instrument Flight Software for a 
Constellation 

The Instrument Flight Software f or Firmware - be to 
processor software or FPGA VHDL Code significantly 
affects the cost model. The flight software complexity 
affecting the model is designated as f or f/m, where m is 
the number of homogeneous spacecrafts/instruments in the 
constellation configured with the same instrument 
software with the S/W development costs counted only 
once. The software size f also bears on model cost. The 
cost model then includes the associated S/W parameter f: 

Icc = f({P, P r , ty}, { d ijX , Z, S, S r }, {W, D, D r }, {I, I r ; L, 
TDI}, { F, F r }, {R,R r }, {O, O r },f) 

6.2 Computation Arithmetic 

Furthermore, the choice of arithmetic A - floating-point as 
opposed to fixed-point arithmetic affects 

- Input Data Dynamic Range 

- Allowable Depth of Computations before 
loosing precision 

- Processing Time Depth. 

In other words, the arithmetic choice parameter bears 
significant design costs, increasing with fixed-point, in 
particular and reflecting in the cost model: 

Icc = f({P, P r , ty}, { dy„ Z, S, S r }, {W, D, D r }, {I, I r ; L, 
TDI}, { F, F r }, {R, R r }, {O, O r }, {f}, {A, A r }) 

6.3 Calibration Sources Complexity 

And finally, the calibration sources complexity must be 
taken into account by introducing parameter M for 
modeling the science phenomena data sources. This 
completes the new enhanced cost model framework: 

Icc = f({P, P r , ty}, { dy„ Z, S, S r }, {W, D, D r }, {I, I r ; L, 
TDI}, {F, F r }, {R, R r }, {O, O r }, {f}, {A, A r }, M) 

7.0 Enhanced Cost Model Using Complexity 
Index 

The heritage instrument performance model in use for 
heritage instrument cost evaluation is based on throughput 
parameters P, D, P r , D r and heritage hardware designs H: 

v = v(P, D) 

u = u(v, v r , H) = u(P, D, P r , D r , H) 

A complex instrument data system must be designed to 
handle the largest data volume and data rates determined 
by all parameters and by employing new solutions in 
reconfigurable hardware (RC). The enhanced cost model 
depends on the system complexity index K derived from 
the complexity parameters: 



V = max(P, S, D, I, F, R, O, f, A, M) 

V r = max(P r , S n D r , I r , F r , R r , O r , A r , M r ) 

U = U(V, V r , RC, K) = U(P, S, D, I, F, R, O, f, A, 
M, P r , S r , D r , I r , F r , R r , O r , A r , M r , RC) 

It is not that the parameters were not in the considerations 
before. However, their affects were so negligent in 
comparison with P and D parameters, that they could be 
reasonably ignored at conceptual level design. When they 
were considerable, the heritage ASICs (Fig. 6) 
implementation came to the rescue sometimes 
accompanied by costly re-designs. 

7.1 Empirical Evaluation of the Enhanced Cost 
Model 

If heritage cost model u = u(P, P r , D, D r , H) resulting cost 
was u=5 * $X (in some heritage cost unit, say millions of 
dollars) or $5X, where 5 was the number of parameters in 
the heritage cost model, namely the parameters P, D, P r , 
D r . The enhanced cost model empirical evaluation can be 
represented as 

U = U(V, V„ RC, K) ~ u(v, v r , H) + K(V, V r ) or 
U = u + $k = u + ($4.0 million dollars) 

The cost adjustment parameter k is an empirical 
evaluation of the complexity index 

K = K(V,V r )~k 
where k was derived as 

K(V, V r )~k = ( (||V|| + ||V r ||) / (||v|| + ||v r ||) ) 

In this paper k = (20/5) = 4.0, where 20 is the number of 
complexity parameters in the enhanced cost model and 5 
is the number of parameters in the heritage cost model. 
Factor k is also based on the experience gleaned from the 
development of a few recent missions, and expressed as 
the heritage cost model adjustment, in k millions of 
dollars ($k x 10 6 ). Factor k can be refined in future work 
as complexity index K=K(V, V r ) gets a better formulation 
and by design optimization outlined below in Section 8. 

The sequence of these complexity parameters comprises 
the nodes on the guiding line from the heritage cost model 
u to the new enhanced cost model U (Fig. 4): 

PSDI FROfAM 

P r S r D r I r F r R r O r A r M r RC 

oo oooooo ooo 



u(v, v n H) U(V,V n RC,K) 

Figure 4. Guiding Line From Heritage Cost Model u to 
the Enhanced Cost Model U 


7.2. The Enhanced Cost Model 

The enhanced cost model dependencies diagram presents 
the heritage inputs to the model, its functionality, as well 
as all the complexity parameters enumerated in this paper. 



Figure 5. Enhanced Cost Model Dependencies 






8.0 Implementation Options and Design to 
Complexity Parameters 

The cost for contemporary complex instruments 
discourage ASIC based design solutions. The current and 
future instruments are characterized by complexity 
parameters that are larger than P and D by orders of 
magnitude, resulting in the need to reconsider the IDPU 
complexity and cost models more explicitly. The resulting 
enhanced cost model is very different from the heritage 
cost model, as depicted in the Enhanced Cost Model 
Diagram in Figure 5. The new solutions for complex 
instruments are based on FPGA/RC technology 
implementations, which also allow solutions for a larger 
class of problems, but at a lower cost than with ASICs. 
Some implementation options for complex instruments are 
shown in a graphical form in Figure 6. 

8.1 Implementation Options 
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Including 
software 
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Figure 6. Comparative Costs of ASIC and FPGA 
Solution Implementations 


In Picture 6 the inner white circle is an icon for a Complex 
Signal and Data Processing Application. Its encompassing 
solution is depicted in dark for an ASIC implementation 
and in white for an FPGA/RC implementation. Both solve 
larger problems at a cost. 

8.2 Design of an EE Subsystem to Complexity 
Parameters 

Contemporary complex instruments and their electrical 
and electronics data sub-systems must be designed from 
the conceptual outset to their complexity parameters and 
include these performance complexity parameters in the 
enhanced cost model U. The design to complexity 
parameters and its optimization may greatly affect the cost 
associated with the instrument complexity index K, or 
even change its sign, resulting in overall cost reduction. 
For instance, an improvement of an on-board 
computational algorithm by a factor of 2 is huge because 
of the cost of on-board resources, while on the ground it is 
not worth the effort to achieve it. The design and 
optimization of an instrument on-board data system can, in 
turn, significantly affect the value and sign of the new cost 
model for the complexity index K, reducing costs in other 
parts of the mission, like downlink bandwidth and ground 
processing. 

For example, in instruments dealing with weak 
measurement signals, an on-board digital TDI 
computation is an algorithm of choice. The n-step TDI 
(TDI-n) algorithm is critical in improving the signal-to- 
noise ratio for weak Near Infrared (IR) and thermal band 
signals by a factor of sqrt(n). As a byproduct of TDI-n 
process, the downlink data volume is decremented by a 
factor of n. However, while source signal noise 
randomness accounts for averaging it out the analog signal 
digitization noise only adds up in lower bits of the digital 
counts and the lower two bits in the TDI output need to be 
discarded. The design to the intermediate parameter / 
requires that the ADC is 2-bits wider than top-level 
requirements for the width of the downlink counters. On 
the other hand, the TDI computation of complexity O on 
this larger volume of intermediate data can be optimized 
by a factor of at least 2 by replacing the operation of 
division with multiplication by a pre-computed and stored 
in a small table of multiplicands 1/j, for 1<= j <= 24. 

In any contemporary implementation of the operation of 
division the division takes 15-25 clock cycles, as 
compared to 3 cycles for subtraction, addition, and 
multiplication. When there is a short computation (like a 
TDI-6), involving five additions (+), and a single division 
(/), the division is much more lengthy in time cycles’ 
duration than an entire TDI computation (aj + a 2 + a 3 + a 4 
+ a 5 + a s)/6, where d are the detector pixels signal 
measurements for ground pixel a at consecutive dwelling 
times tj. 



However, when the dividers are known in advance and 
their number is small, for example in a TDI-j computation 
(l<=j<=24), their inverse can be pre-computed and stored 
in a small table. Then, instead of division implementation 
in FPGA or its computer use, can be replaced by 
multiplication making the entire computation at least twice 
faster and coherent without any additional resources for an 
FPGA divider circuitry. 

The design and development of the electronics data 
subsystem, based on the above derived complexity 
parameters, requires personnel labor and reconfigurable 
hardware, commensurate with the resulting correction 
factor k. Namely, it is empirically known that each million 
of dollars in cost is equivalent to 3 Full Time Equivalent 
developer labor units (FTEs). The cost attributed to 
complexity index K=5 can be approximated by (3*k) 
FTEs (approximately 15 FTEs) over the mission 
development period, in addition to the heritage cost which 
basically covers the materials, manufacturing and 
processor software, rather than the design to the complex 
parameters. 

Conclusions 

We characterized the class of representative complex 
instruments as Class II of RC-hardware-centric data 
processing instruments. In such instruments the 
complexity of on-board analog signal and digital data 
processing in reconfigurable hardware far supersedes that 
in the general-purpose heritage processors. For such 
instruments the EE subsystem development effort 
supersedes the heritage software-centric development 
methodology and an enhanced cost model must be applied 
to it. We have then analyzed the new representative 
complex instrument top-level requirements and associated 
data volumes, rates and on-board computational 
algorithms’ RC implementations. We enumerated the EE 
subsystem data processing complexity parameters and 
functions V, V r and introduced the instrument complexity 
index K(V,V r ). We then introduced the complex 
instrument EE subsystem enhanced cost model framework 
U(V, V r , RC, K). Cost Model U is based on labor required 
to design for the complexity parameters and on cost of 
reconfigurable hardware. For complex instruments the EE 
subsystem must be designed to the complexity parameters 
one-by-one at the outset conceptual level. The costing 
must use the enhanced cost model U that is based on the 
complexity parameters in order to avoid consecutive 
development costs’ diversions and schedule overruns. The 
costs associated with the complexity parameters can be 
estimated in heritage ways, as long as the complexity 
parameters are costed at the outset conceptual level design 
and converted to labor and RC hardware inputs used by a 
heritage cost model. We derived the empirical evaluation 
of the enhanced cost model function as U ~ u + k(K). 


Factor k(K) can also be viewed as the baseline cost of a 
complex instrument EE subsystem data. Future work 
consists in implementing the enhanced cost model 
framework into a cost engineering tool. 
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Abstract. Development costs of a few recent spaceflight instrument electrical and 
electronics subsystems have diverged from respective heritage cost model predictions. 
The cost models used are Grass Roots, Price-H and Parametric Model. These cost models 
originated in the military and industry around 1970 and were successfully adopted and 
patched by NASA on a mission-by-mission basis for years. However, the complexity of 
new instruments recently changed rapidly by orders of magnitude. This is most obvious 
in the complexity of representative spaceflight instrument electronics’ data system. It is 
now required to perform intermediate processing of digitized data apart from 
conventional processing of science phenomenon signals from multiple detectors. This 
involves on-board instrument formatting of computational operands from row data (for 
example, images), multi-million operations per second on large volumes of data in 
reconfigurable hardware (in addition to processing on a general purpose imbedded or 
stand-alone instrument flight computer), as well as making decisions for on-board system 
adaptation and resource reconfiguration. The instrument data system is now tasked to 
perform more functions such as forming packets and instrument-level data compression 
of more than one data stream, which are traditionally performed, by the spacecraft 
command and data handling (C&DH) system. It is furthermore required that the 
electronics box for new complex instruments is developed for one-digit watt power 
consumption, small size and that it is light-weight, and delivers super-computing 
capabilities. The conflict between the actual development cost of newer complex 
instruments and its electronics components’ heritage cost model predictions seems to be 
irreconcilable. This conflict and an approach to its resolution are addressed in this paper 
by determining the complexity parameters, the complexity index, and the use of these in 
the enhanced cost model. 
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1 .0 Introduction 


The representative complex spaceflight instruments and prototypes are, for example, the 
Ocean Carbon Ecosystem and Near Shore Processes Mission (OCEaNS) optical 
instrument with high volume and high rate data streams from its focal planes and 
requiring on-board digital time delay integration. The non-optical Magnetospheric Multi- 
Scale Fast Plasma Investigation (MMS/FPI) instruments require on-board intensive 
computation of the Burst Quality Index. The Laser Interferometer Space Antenna (LISA) 
may require quad precision floating-point arithmetic computations and the Solar Viewing 
Interferometer Instrument Prototype (SVIP) is based on image processing within fast 
attitude control loops. A complex instrument is one that has large arrays of large detectors 
at fast readout rates, producing signal volumes and rates of order of magnitudes higher 
than heritage instruments and instrument based random access memory around 500 
megabytes, and requiring non-trivial analog signal and digital data processing on-board 
the instrument. 

There is a solution - to fly a super-computer, but obviously, it is not feasible. There is 
another solution at the other end of the spectrum of possible solutions. It is in utilizing 
reconfigurable hardware (RC) to achieve on-board super-computer power as a substitute 
for a super-computer. However, this technologically possible solution is tempting, at the 
conceptual design phase, to make an assumption that this solution can be implemented 
by the heritage design methodologies of scaling up a heritage instrument design (“a 
bigger box ” approach). This turns out to be a strong assumption and at the following 
design development and implementation phase results in merely a partial solution. In 
turn, a partial solution invariably requires re-designs during the development phase, 
which leads to divergence of development costs from cost model predictions. 

In order to find the full design solution for a complex instrument at the outset conceptual 
level and cost the full design, the instrument complexity parameters must first be 
determined from the requirements and accounted for in the conceptual design. The 
complexity parameters and the conceptual design to these complexity parameters must 
then be included in the instrument cost model. Once the instrument complexity 
parameters are analyzed then the labor and hardware cost, required for the instrument 
design to these parameters ( Section 8), can be estimated using heritage cost models or 
accounted for in the enhanced cost model and alleviate the cost divergence problem. 

The elaboration of the complexity parameters in this paper in Sections 2-7 is straight- 
forward, including the framework for the proposed enhanced cost model that is using 
these complexity parameters and the complexity index derived from them, as well as the 
empirical cost factor based on the complexity index. The design of the Electrical and 
Electronics (EE) Subsystem to the complexity parameters at conceptual phase is 
presented in Section 8. 
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2.0 Complexity Parameters and the Enhanced Cost Model Methodology 

In order to develop an enhanced cost model for complex instruments, a few preliminary 
issues have to be discussed. Most subsystems within the newer complex instruments 
closely follow the typical heritage instrument. For example, their mechanical and thermal 
subsystems, except for change in dimensions for small satellites or large observatory, are 
similar to heritage ones. However, the requirements for the electronics’ data subsystem 
has undergone radical changes and its complexity parameters must now be reflected in 
the cost model. The sources of complexity are described below and the sequence of the 
complexity parameters can be depicted as selected points on the guideline from the 
heritage cost models to the enhanced cost model (Figure 4). 

2.1 Sources of Complexity Parameters 

The complexity parameters are derived based on the detector analog signal and on-board 
digital data processing flow from the source phenomena to the spacecraft solid-state 
recorder (SSR), with the emphasis on their information communications’ aspects. The 
methodology we used in deriving the complexity parameters and the enhanced cost 
model can be described by enumerating the main points of the analysis followed by 
enhanced cost model framework synthesis. The on-board sources of analog signals and 
digital data are as follows: 

• External to spacecraft and instrument 

o Science Phenomenon (measured by large arrays) 
o External Calibration Sources (Analog - distant star, sun, moon) 
o Spacecraft Commands (Digital Data from Ground/Space Link) 
o GPS Position Data and Time Signals 

• Internal to spacecraft and instrument 

o Science Analog-to-Digital Conversion Output 
o On-Board Intermediate Data Processing Results 

■ Pre-Processing i.e. frame formatting, packetization 

■ On-board Processing i.e. signal processing, time delay integration, 
data compression, time tagging, high performance computation 

• Engineering 

o Internal Calibration Sources 
o Housekeeping Data Sources 

2.2 Methodology Developmental Steps 

The enhanced cost model methodology is derived using the following steps: 

• Informal Table of Signal and Data Sources 

• Formal Classification Matrix of Sources for Analog Signals and Digital Data 

• Source Signal Pixel and Detector Super-Pixel 

• Mapping Signal Sources Onto Instrument Detectors and On-Board Data 
Processing Complexity Parameters Origin 
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• Instrument Cost Model emergence from heritage cost to the enhanced cost 
model. 

2.3 Cost Models and Complexity Cost Distribution Outline 

The Heritage Cost Models (HCM) u are based on the four primary parameters of two 
functions v, v r representing an implementation labor and heritage hardware cost 
parameter H described as: 

Heritage Cost Model (HCM) 
v = f(P,D) 
v r = f r (P r , D r ) 

u = u(f(P, D), f r (P r , D r ), H) = u(P, D, P r , D n H) 


where P is the number of analog signals, D is the number of digital signals, P r is sampling 
rate for analog signals and D r is sampling rate for digital data. 

The enhanced cost model U is based on the heritage cost model u parameters and the 
derived complexity parameters of functions V and V r implementation labor. 

U depends on design of the reconfigurable hardware (RC) to the complexity parameters 
and complexity index K, derived from the instrument data system complexity parameters, 
as described in the following Sections. 

Enhanced Cost Model (ECM) 

V = max(P, S, D, I, F, R, O, f, A, M) 

V r = max(P r , Sr, Dr, Ir, F r , R r , Or, A r , Mr) 

U = U(V, Vr, RC, K(V, Vr)) = U(P, S, D, I, F, R, O, f, A, M, 

P rt S r , D r , Ir, F r, Rr, O r , A r , M r , RC) 

where P, D, P r and D r are described above and the new parameters are derived below. 

2.3.1 Complexity Costs Placement 

The placement of costs, induced by instrument electronics subsystem complexity 
index K in the enhanced cost model is of most importance. It is not in scaling up the 
direct labor or hardware costs for a heritage design and implementation or its funding 
reserves in which the complexity parameters are not costed one by one. The placement of 
cost in the enhanced cost model should rather be in the labor and hardware costs for 
finding a full solution and design that includes all complexity parameters one by 
one. The cost should also account for labor and hardware needed for pre-optimizing the 
design for an instrument with the index of complexity K and for tuning a complex 
electronics subsystem at all phases along the design implementation path. 

In other words, the placement of the costs associated with the EE subsystem complexity 
occurs at all the phases of a project life cycle. This can be accomplished in two ways: 
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1) Complexity costs are manually converted by a user to costs in labor and 
hardware inputs, when a heritage cost model is used; Even a heritage cost model 
u results in more accurate cost predictions, if it takes into consideration all 
complexity parameters at conceptual design phase (Figure 4) 

2) In future work one of the heritage cost models shall be modified to include 
complexity parameters in its database, yielding the enhanced cost model 
implementation as a new commercial tool. 

In both case the cost of complexity parameters placement is based on: 

Analysis of the requirements ’ complexity 

Complexity risks ’ assessment and mitigation by pre-proposal studies and RC 
hardware experiments simulations 
Finding a solution at conceptual design phase 

Synthesis of solution, including RC algorithms’ pre-hardware optimization. 

2.4 Implementation Steps 

• Instrument Data Processing Unit (IDPU) complexity implementation options are 
analyzed 

• Design of a complex instrument to the complexity parameters is implemented at 
conceptual level and costed using the enhanced cost model framework. 

3.0 Sources of Instrument Analog Signals and Digital Data 

Heritage instruments were “throughput systems” from an instrument focal plane sensor 
source to destination - the spacecraft computer system and its solid-state recorder (SSR), 
in relation to the analog signal and digital data communications aspect. For example, a 
heritage instrument, such as the SeaStar spacecraft Wide-Field-of-view Sensor 
(SeaWiFS) instrument comprises a few sensors with a small number of homogeneous 
source pixels - a source of a small number of analog signals P that are sampled at 
moderate sampling rate P r . After digitization of P by the instrument, the digital data is the 
instrument output at data volume and rate (D, D r ). The digital data is then just forwarded 
to the spacecraft for processing and compression by one of the spacecraft computers and 
storage in the spacecraft SSR. The digital data volume essentially amounts to the volume 
of source pixels P multiplied by the analog-to-digital conversion (ADC) word length 
(usually => 10 to 16 bits), while the digital data rate in words is the same as the rate of 
source pixel signal sampling. Exception among heritage instruments was a large 
Observatory with complexity handled by costly Application Specific Integrated Circuits 
(ASIC). However, the large observatories, long-term schedules and multi-million dollars 
ASICs are not a common option today. 

Representative advanced instruments of today and tomorrow are much more complex 
with strict cost limitations and short schedules. These instruments study multiple non- 
homogeneous phenomena at different sampling rates and digitization widths, as well as 
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perform computationally intensive on-board digital data processing and compression 
within the instrument. For example, On-Board fast optics control loops require 
processing by the instrument of large CCD images (512 x 256 pixels) at hundreds of 
frames per second. 

This, in turn, requires a new look at the affects of complex instrument’s different signal 
and digital data sources and their volumes and rates on the instrument complexity (power 
consumption in particular) and cost. This is required in order to enhance the instrument 
electronics cost model at early stages of the instrument conceptual design, when 
instrument initial complexity and cost are evaluated at proposal and feasibility studies’ 
levels. 

It is not that such parameters were not accounted for in heritage instrument cost models. 
However, their impact so negligent, in comparison with that in newer instruments, that 
they could be reasonably ignored at conceptual level design. 

For newer complex instruments any omissions in costing the complexity of on-board data 
processing at the early conceptual level design of a complex instrument or the Technical 
Management Review Package (TMR), or in a Final Research Proposal, could result in 
eventual project cost underestimation and schedule overruns. 

In order to derive the new instrument’s complexity parameters there is a need to take a 
closer informal look at the set of all the sources of signals and data and then formalize 
this set using the mathematical construct of a matrix. This matrix is then used to derive 
the new complexity parameters. This is done in the remainder of this Section and the 
following Section 3. 

3.1 External to Instrument and Spacecraft Signal Sources 

3.1.1 Science Signal Sources 

The advanced subject instrument’s science and engineering (calibration or housekeeping) 
signals originate from some physical phenomenon. The science data originates with 
measurements by the instrument detectors of the source signals’ amplitude. 

3.1.2 External Calibration Sources 

Distant Star 

Sun 

Moon 

Orbit Night Sky or Spacecraft Dark Side 
Earth Horizon 
Bright Cloud 

3.2 Internal or Engineering Signal Sources 

The engineering data originates with the instrument itself, namely within the 
housekeeping detectors (thermal, pressure, force gouges, instrument or spacecraft power 
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sources and other sensors) or instrument science detectors calibration sources, which are 
emulating natural physical phenomenon for the science physical phenomena detectors. 

3.2.1 Internal House-Keeping Signal Sources 

Thermistors, Force sensors 

3.2.2 Calibration Signal Sources 

Instrument-carried calibration sources - hot/cold plates, illumination spheres, etc. 

3.3 Instrument Digital Data Sources 

There is also some instrument digital data that originates in the instrument data 
(information) system apart from its detector signal ADCs (computation registers, 
intermediate digital data, telemetry format headers memory, SSR), and which needs to be 
transmitted to upper nodes of the spacecraft for communication to the ground control 
station or other spacecraft in a constellation. The physical phenomena itself can be 
comprised of electromagnetic radiation in different spectral ranges (ultra-violet, visible 
light, near Infrared or IR, thermal IR, communications radio-frequency or RF waves), 
mechanical forces, gravitation, chemical processes. These are also termed analog signals 
and, in turn, may have as their sources the sun, moon, a star, celestial background 
radiation or surface of planets - earth land and oceans’ upward irradiation. 
Communications RF sources are, for example - commands, up-linked from a terrestrial or 
space control center to spacecraft and instrument. 

3.4 Informal Signal and Data Sources Classification Table 

Pictorially the set of all instrument analog signal and digital data sources, which 
contribute to instrument information, can be represented in an informal Table, Figure 1. 


Phenomena of 

House-Keeping 

Commands 

Internal to 

Science interest, 

sources and signals 

(CMD) or 

instrument 

Calibration 

(H/K), 

Signal Class 3: 

Digital Data 

Sources Signals 

Thermistors, 


Sources & 

Class 1 : 

Mechanisms’ 


Computations 


Position sensors or 


(IDS) or 


Signal Class 2: 


Signal Class 4: 

S1I9 Si2»»« Sjk 

S21 ... S2n 

S31 ... S3 m 

S 4 I ... S4y 


Figure 1. Classification of Instrument Analog Signals and Digital Data Sources 
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4.0 Formal Classification of Sources for Analog Signals and Digital Data 

The informal multi-classification of instrument analog signal and digital data sources in 
Figure 1 can be further formalized into an extended matrix as depicted in the following 
Figure 2. The source with most elements (H/K is perhaps the one, because it contains 
dozens of thermistors) is 

{S21 ... S 2 n} 

It comprises the class of the longest non- zero energy source of signals. Other sources for 
other analog signals and digital data are extended by zero-value elements to yield a 
sparsely populated “4 x n” rectangular extended matrix of instrument data sources. 

Si 1 Si 2 ... Sik0ik+1 ... Oin 
S21 S22 ... S 2 n -1 S 2 n 

S 3 1 ... S3 m 03 m +i ... O 31 , 

s 4 i... s 4v 04v+i... 0 4n 

Figure 2. Extended Matrix of Instrument Data Sources 

This formal classification matrix is used in the following Sections to derive the new 
instruments complexity parameters, which are further, used to develop the enhanced cost 
model for the electronics sub-system. 

5.0 Mapping Signal Sources Onto Instrument Detectors 

We will examine now the propagation of the signal and data elements from the formal 
matrix of sources (Figure 2) throughout an instrument and associated complexity 
parameters. 

A physical phenomenon manifests itself in emanated energy from some finite size (for 
example, 1 km x 1 km) surface or volume region - source signal pixel and this energy is 
being intercepted by an instrument detector, as a sub-pixel, pixel or super-pixel (binning 
of a few adjacent CCD pixels, for example (Figure 3). 

5.1 On Source Signal Pixels and Detector Super-Pixels 

A Source is usually associated with some finite size geometric space, say a terrestrial 2-D 
surface or 3-D volume (source pixel), or a small spot on an instrument surface for 
mounting a thermistor - a temperature signal detector as listed in Figure 1 above. For 
example, consider two sources: 

A ground track of dimensions L x h and ground pixel of size h x h 
A spot on an instrument surface of radius r for mounting a thermistor 
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Stylized Swath of L Source Pixels 


■ 

■ 

Ground Track scanned by a spacecraft instrument telescope 

■ 


h 



A circular spot on instrument surface 
to mount a thermistor 


Figure 3. Geometry of Source Pixels 


The number P of source pixels for the instrument is the sum of all non-zero elements in 
the above matrix M: 


P = I(sy) 

5.2 On Mapping Signal Sources Onto Detectors and Complexity Parameters 

Instrument sensors invariably comprise a set of detectors or sensing pixels out of which a 
super-pixel dy of size Z (say, Z = 3 x 3) is comprised. For example, a CCD comprises a 
2-D array of (n x m) sensing pixels that can be organized into a set of super-pixels on the 
CCD itself. An InGaAs linear array comprises a linear array of (1 x k) pixels and a 
housekeeping thermistor sensor usually comprises a single pixel thermal detector. 

Each signal source sy is further defined by its measurement interval ty in fractions of a 
second (or sampling rate derived from this time as its inverse with frequency in Hz units). 

Although the sampling of different sources may not be asynchronous, the source 
sampling interval provides the definitive answer on the information volume of a signal 
source from communication point of view - in terms of source measured pixels per 
second. 

It is obvious that at some time T the different samplings may intersect in time and that 
the instrument must be designed to handle the maximum combined data volume rate of 

P r = X(sy / ty) pixels per second for all i, j; the division is 0 for sy=0 

P and P r , the volume of the instrument observed source pixels and sampling rates 
handled by the instrument are the two important first parameters to consider in the 
evaluation of the instrument complexity and cost or I cc : 

I cc = f({P, P r }...) 
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Next, the energy of a group of adjacent source pixels sy energy is intercepted by an 
optical system and concentrated on a so-called Time Delay Integration slit of length 
determined by the TDI-size. This slit length L (in adjacent source pixels) is mapped into 
a TDI-size = L detector’s spectrometer and each TDI input pixel is distributed over a 
column of detector L super-pixels dy. 

A source pixel’s energy may further be practically instantaneously distributed in some 
spectral band over an I-row of dyx detector super-pixels (CCD row) by different optical 
means, such as diffraction gratings. 

This mapping of physical phenomena source pixels sy onto instrument detector pixels 
results in the next level of data complexity, the number of detector super-pixels S, 
namely 


S = ( I(dij) ) / Z >= L x k 

It is reasonable to evaluate the detector pixels’ sampling rate by above dyx and say that 

Sr = X(dijx/tij) 

The number S may be larger than P by an order of two magnitudes and it becomes the 
next important parameter in figuring out the Icc, namely: 

ICC = f({P, P r ,tij}, (S, S r }...) 


where S > (P x (>,=>60)) or 

1 source pixel is mapped onto detector /. spectral super-pixels on one CCD row per 
sampling time ty. 

The next level of instrument complexity stems from the detector super-pixel digitization 
into a fixed number of information bits b(dyx). This internal to the instrument data source 
is the detector source super-pixel analog-to-digital signal’s converter ADCyx, resulting in 
a detector pixel digital data volume and corresponding digital data rate from analog and 
ADC board to the instrument digital information processing board or instrument data 
processing unit (IDPU): 


D = B d l]X x b(d ijI ) ) 


Dr = B djj>. x b(djjx) X tjj ) 


D and D r are the instrument internal digital data volumes and rates that may be orders of 
magnitude higher than then the previous level parameters S and S r , which are related to 
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analog data sources. This is because the digitization width b(dy,) => W=>14 bits within 
advanced instruments of today and tomorrow and it further contributes to Ice: 

Icc = f({P, P r , tij}, { (dij, Z), k, S, S r }, {W, D, D r } ...) 


Next comes the on-board processing of the intermediate digital information within the 
instrument which involves transforming D, D r into Intermediate data I and Intermediate 
rates I r that may be larger than D and D r by a factor of L = 2 or more. For example, 
converting the W=14-bit ADC counters into a 32-bit integer or single precision floating- 
point numbers, doubles (32/14 = factor L>2) the volume and rate of ADC digital data to 
be processed within an 1DPU or 


I = 2 x D 
I r = 2 x D r 

On-board post-ADC digital data Interpolation within an instrument IDPU (required in 
running some on-board algorithms) and data paketization overhead may increase the data 
volume and rate by a factor of L>10. Digital domain Time Delay Integration (TDI) may, 
in turn, decrease the intermediate data volume and rates at the price of required 
computational resources to implement the TDI algorithms. This further contributes to the 
Icc: 


Icc = f({P, P r , tij}, { dij,, Z, S, S r }, {W, D, Dr}, {I, Ir, L, TDI} ...) 

Instrument detector calibration and fault detection may require, for example, to dump the 
entire CCD or an IDPU memory region. This requires the instrument to be able to handle 
data rates determined by native pixel-frame size and rate of full dump, say F, F r or 

Icc = f({P, Pr, tij}, { dij,, Z, S, Sr}, {W, D, Dr}, { I, I r ; L, TDI} {F, Fr}...) 

Furthermore, instrument-level data volume Reduction using Compression techniques by 
a pre-determined minimum factor (for example 2:1 lossless compression) may also 
reduce the data volume and rate to R, Rr. Itbears on instrument complexity and cost: 


Icc = f({P, Pr, tij}, { dij„ Z, S, Sr}, {W, D, Dr}, {I, I r ; L, TDI}, {F, Fr},{R, Rr} ...) 


6.0 On-Board Computational Complexity 

Following is the list of representative flight processors that demonstrates the on-board 
heritage computational resource: 

FAST 10 MHz general-purpose processor 

SeaStar 16 MHz a set of three primary and three backup microprocessors 

TRMM 133 MHz general-purpose processor. 
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The heritage instruments, as exemplified by the instruments on spacecraft missions 
TRMM, SeaStar and FAST, could be characterized as 
Class (I): 

• High data volumes and rates 

• Electronics Box is essentially through-putting high rate data to spacecraft (SC) 
Solid State Recorder (SSR) 

• Low volume data is processed by the instrument data system computer 

• These instruments are low performance software - centric and their software 
aspect is preeminent. 

Advanced complex instruments, such as the MMS/FPI instruments require more than 
0=40 Millions of Operations per second on more than O r — 10 Million bits per second 
data streams in single and double precision floating point arithmetic. 

Complex instruments can be characterized as RC-Hardware-Centric Data Processing 
Instruments or 
Class (II): 

• High data volumes and rates 

• Electronics Box is performing on-board high performance data processing in RC 
hardware as opposed to heritage ASIC 

• Low volume data is processed by the instrument data system computer 

• These instruments are high performance hardware - centric data processing 
instruments and their software aspect is minimal. 

It is obvious from laboratory simulations that by only changing the type of variables from 
single precision to double precision, increases a small application’s run time by a factor 
of. Changing data types 2 and to quad precision increases the run time by an order of 
magnitude. This is to simply demonstrate that on-board computations within an IDPU for 
an advanced instrument is not possible with heritage resources and requires FPGA 
implementations supplemented by host processors. In Class (II) instruments the 
Hardware (H/W) aspect of the Data System is the driver and the Software (S/W) aspect is 
minimal. This must be reflected in resource allocation, where 

S/W FTE « H/W FTE 

Because of this the computational complexity parameters O and O r (where often O r =D r ) 
must be included in the instrument IDPU conceptual design and cost model: 

Icc = f({P, P r , tij}, { djjx, Z, S, S r }, {W, D, D r }, {I, I r ; L, TDI}, { F, F r }, 

{R, R r }, {O, O r }) 
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6.1 Instrument Flight Software for a Constellation 

The Instrument Flight Software f or Firmware - be to processor software or FPGA 
VHDL Code significantly affects the cost model. The flight software complexity 
affecting the model is designated as f or f/m, where m is the number of homogeneous 
spacecrafts/instruments in the constellation configured with the same instrument software 
with the S/W development costs counted only once. The software size f also bears on 
model cost. The cost model then includes the associated S/W parameter f: 

Icc = f({P, P r , I*}, { dp, Z, S, S r }, {W, D, D r }, {I, I r ; L, TDI}, { F, F r }, 

{R, Rr}, {O, Or}, f) 


6.2 Computation Arithmetic 

Furthermore, the choice of arithmetic A - floating-point as opposed to fixed-point 
arithmetic affects 

Input Data Dynamic Range 

Allowable Depth of Computations before loosing precision 
Processing Time Depth. 

In other words, the arithmetic choice parameter bears significant design costs, increasing 
with fixed-point, in particular and reflecting in the cost model: 

Icc = f({P, P r , tij}, { dp, Z, S, Sr}, {W, D, Dr}, {I, I r ; L, TDI}, { F, Fr }, 

{R, Rr}, {O, Or}, {f}, {A,Ar}) 

6.3 Calibration Sources Complexity 

And finally, the calibration sources complexity must be taken into account by introducing 
parameter M for “Mimicking science phenomena” data sources. This completes the new 
enhanced cost model framework: 


Icc = f({P, Pr, tij}, { dp, Z, S, Sr}, {W, D, Dr}, {I, l r ‘, L, TDI}, { F, Fr }, 

{R, Rr}, {O, Or}, {f},{A,A r }, M) 


7.0 Enhanced Cost Model Using Complexity Index 

The heritage instrument performance model in use for heritage instrument cost evaluation 
is based on throughput parameters P, D, P r , D r and heritage hardware designs H: 

v = v(P, D) 

Vr=V r (P r , D r ) 

u = u(v, V r , H) = U(P, D, P r , D r , H) 

A complex instrument data system must be designed to handle the largest data volume 
and data rates determined by all parameters and by employing new solutions in 
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reconfigurable hardware (RC). The enhanced cost model depends on the system 
complexity index K derived from the complexity parameters: 

V = max(P, S, D, I, F, R, O, f, A, M) 

Vr — max(P r , Sr, D r , I r , F r, Rr, Or, A r , M r ) 

U = U(V, Vr, RC, K) = U(P, S, D, I, F, R, O, f. A, M, 

Pr, Sr, Dr, l r , F r , R r , O r , A r , M r , RC) 

It is not that the new cost model parameters S, I, F, R, O, f, A, M and their corresponding 
rate parameters S r , I r , F r , R r , O r , A r , M r were not in the considerations before. However, 
their affects were so negligent in comparison with P and D parameters, that they could be 
reasonably ignored at conceptual level design. When they were considerable, the heritage 
ASICs implementation came to the rescue sometimes accompanied by re-designs , at a 
significant cost at depicted in the following Figure 5. 

7.1 Empirical Evaluation of the Enhanced Cost Model 

If heritage cost model u = u(P, P r , D, D r , H) resulting cost was u=5 * $X (in some 
heritage cost unit, say millions of dollars) or $5X, where 5 was the number of parameters 
in the heritage cost model, namely the parameters P, D, P r , D r . The enhanced cost model 
empirical evaluation can be represented as 


U = U(V, V r , RC, K) ~ u(v, Vr, H) + K(V, V r ) or 
U = u + $k = u + ($4.0 million dollars) 

The cost adjustment parameter k is an empirical evaluation of the complexity index 


K = K(V, V r )~k 

where k was derived as 

K(V, V r ) ~ k = ( (||V|| + ||V r ||) / (INI + INI) ) 

In this paper k = (20/5) = 4.0, where 20 is the number of complexity parameters in the 
enhanced cost model and 5 is the number of parameters in the heritage cost model. 
Factor k is also based on the experience gleaned from the development of a few recent 
missions, and expressed as the heritage cost model adjustment, in k millions of dollars 
($kM). Factor k can be refined in future work as complexity index K=K(V, V r ) gets a 
better formulation and by design optimization outlined below in Section 8. 

The sequence of these complexity parameters are the nodes on the guiding line from the 
heritage cost model u to the new enhanced cost model U: 

PS D I F R O f AM P r S r D r I r F r R r O r A r M RC 


u(v, v r Jt) U(V, V r ,RC,K) 

► 

Figure 4. Guiding Line From Heritage Cost Model u to the Enhanced Cost Model U 
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7.2. Enhanced Cost Model Diagram 

The enhanced cost model dependencies diagram present time inputs to the model and its 
functionality, as well as all the complexity parameters enumerated in this paper. 


Hardware 

Heritage Cost Model 
u = u(P, D, P r , D r , H) 
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Instrument Complexity Index K = K(V, V r ) 
Cost Model Complexity Index Empirical Evaluation 
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K~k=$4.5M 
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8.0 Design of the EE Subsystem to Complexity Parameters and Options 

The cost caps for contemporary complex instruments discourage ASIC and cryogenics- 
based solutions (Figure 6). The instruments of today and tomorrow are characterized by 
complexity parameters that are larger than P and D by orders of magnitude, resulting in 
the need to reconsider the IDPU Complexity and Cost Models more explicitly. The 
resulting enhanced cost model is very different from the heritage cost model, as depicted 
in the Enhanced Cost Model Diagram in Figure 5. The new solutions for complex 
instruments are based on FPGA/RC technology implementations, which also allow 
solutions for a larger class of problems, but at a lower cost than with ASICs. Following 
are some implementation options for complex instruments depicted in a pictorial form. 

8.1 Implementation Options 



FPGA or other than 
ASIC RC 
Implementation 

The height of the 
blue cylinder is the 
cost of an FPGA/RC 
implementation 


ASIC Implementation 

Including software algorithms 
development and implementation 
in ASIC hardware 


The height of the red 
cylinder is the large 
cost of an ASIC 
implementation 


The inner white circle is 
an icon for a Complex 
Signal and Data 
Processing Application. 

Its encompassing solution 
is depicted in red for an 
ASIC implementationand 
in blue for an FPGA/RC 
implementation. 

Both solve larger problems 
at a cost. 


Figure 5. Comparative Costs of ASIC and FPGA Solution Implementations 
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8.2 Design of an EE Subsystem to Complex Parameters 

Contemporary complex instruments and their electrical and electronics data sub-systems 
must be designed from the conceptual outset to their complexity parameters and include 
these performance complexity parameters in the enhanced cost model U. The design to 
complexity parameters and its optimization may greatly affect the cost associated with 
the instrument complexity index K, or even change its sign, resulting in overall cost 
reduction. For instance, an improvement of an on-board computational algorithm by a 
factor of 2 is huge because of the cost of on-board resources, while on the ground it is not 
worth the effort to achieve it. The design and optimization of an instrument on-board data 
system can, in turn, significantly affect the value and sign of the new cost model for the 
complexity index K, reducing costs in other parts of the mission, like downlink 
bandwidth and ground processing. 

For example, in instruments dealing with weak measurement signals, an on-board digital 
TDI computation is an algorithm of choice. The n-step TDI (TDI-n) algorithm is critical 
in improving the signal-to-noise ratio for weak Near Infrared (IR) and thermal band 
signals by a factor of sqrt(n). As a byproduct of TDI-n process, the downlink data 
volume is decremented by a factor of n. However, while source signal noise randomness 
accounts for averaging it out the analog signal digitization noise only adds up in lower 
bits of the digital counts and the lower two bits in the TDI output need to be discarded. 
The design to the intermediate parameter / requires that the ADC is 2-bits wider than top- 
level requirements for the width of the downlink counters. On the other hand, the TDI 
computation of complexity O on this larger volume of intermediate data can be optimized 
by a factor of at least 2 by replacing the operation of division with multiplication by a 
pre-computed and stored in a small table of multiplicands 1/j, for 1<= j <= 24. 

In any contemporary implementation of the operation of division the division takes 15-25 
clock cycles, as compared to 3 cycles for subtraction, addition, and multiplication. When 
there is a short computation (like a TDI-6), involving five additions (+), and a single 
division (/), the division is much more lengthy in time cycles’ duration than an entire TDI 
computation (ai + a 2 + a 3 + a 4 + a 5 + a6)/6, where d are the detector pixels signal 
measurements for ground pixel a at consecutive dwelling times tj. 

However, when the dividers are known in advance and their number is small, for example 
in a TDI-j computation (l<=j<=24), their inverse can be pre-computed and stored in a 
small table. Then, instead of division implementation in FPGA or its computer use, can 
be replaced by multiplication making the entire computation at least twice faster and 
coherent without any additional resources for an FPGA divider circuitry. 

The design and development of the electronics data subsystem, based on the above 
derived complexity parameters, requires personnel labor and reconfigurable hardware, 
commensurate with the resulting correction factor k. Namely, it is empirically known that 
each million of dollars in cost is equivalent to 3 Full Time Equivalent developer labor 
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units (FTEs). The cost attributed to complexity index K=5 can be approximated by (3*k) 
FTEs (approximately 15 FTEs) over the mission development period, in addition to the 
heritage cost which basically covers the materials, manufacturing and processor 
software, rather than the design to the complex parameters. 

Conclusions 

We characterized the class of representative complex instruments as Class II of RC- 
hardware-centric data processing instruments. In such instruments the complexity of 
on-board analog signal and digital data processing in reconfigurable hardware far 
supersedes that in the general-purpose heritage processors. For such instruments the EE 
subsystem development effort supersedes the heritage software-centric development 
methodology and an enhanced cost model must be applied to it. We have then analyzed 
the new representative complex instrument top-level requirements and associated data 
volumes, rates and on-board computational algorithms’ RC implementations. We 
enumerated the EE subsystem data processing complexity parameters and functions V, 
V r and introduced the instrument complexity index K(V, V r ). We then introduced the 
complex instrument EE subsystem enhanced cost model framework U(V, V r , RC, K). 
Cost Model U is based on labor required to design for the complexity parameters and on 
cost of reconfigurable hardware. For complex instruments the EE subsystem must be 
designed to the complexity parameters one-by-one at the outset conceptual level. The 
costing must use the enhanced cost model U that is based on the complexity parameters 
in order to avoid consecutive development costs’ diversions and schedule overruns. The 
costs associated with the complexity parameters can be estimated in heritage ways, as 
long as the complexity parameters are costed at the outset conceptual level design and 
converted to labor and RC hardware inputs used by a heritage cost model. We derived 
the empirical evaluation of the enhanced cost model function as U ~ u + k(K). Factor k 
can also be viewed as the baseline cost of a complex instrument EE subsystem data. 
Future work consists in implementing the enhanced cost model framework into a cost 
engineering tool. 
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